IHHHHUIIIllHHi 

US006654038B1 

(12) United States Patent (io> Patent No.: us 6,654,038 bi 

G^jewska et al. (45) Date of Patent: Nov, 25, 2003 



(54) KEYBOARD NAVIGATION OF NON- 
FOCUSABLE COMPONENTS 

(75) Inventors: Hanta Gajewska, Woodside, CA (US); 

David P Mendenhall, New York, NY 
(US); Peter A. Korn, Oakland, CA 
(US); Michael C. Alters, San 
Francisco, CA (US); Lynn Monsanto, 
San Francisco, CA (US) 

(73) Assignee: Sun Microsystems, Inc., Santa Clara, 
CA(US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended 01 adjusted under 35 
U.S.C. 154(b) by 427 days. 

(21) Appl. No.: 09/586,041 

(22) Filed: Jun. 2, 2000 

(51) Int. CI. 7 G06F 3/00 

(52) U.S. CI 345/802; 345/168; 345/172; 

345/767; 345/854 

(58) Field of Search 345/168, 172, 

345/762-765, 767, 781, 802, 803, 810, 
835, 853, 854 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,625,763 A * 4/1997 Qrne 345/767 

5,721,850 A * 2/1998 Farry et al 345/700 

5,982,351 A * 11/1999 White ct al . 345A72 

6,003,050 A * 12/1999 Silver et al 715/536 

6,072,485 A * 6/2000 Barnes et al 345/163 



6,249,284 Bl ♦ 6/2001 Bogdan 345/764 

6,256,030 Bl * 7/2001 Berry et al 345/854 

6,310,634 Bl * 10/2001 Bodnar et al 345/854 

6,317,144 Bl * 11/2001 Pabla et al 345/784 

6,366,920 Bl * 4/2002 Hoose et al 707/102 

OTHER PUBLICATIONS 

Mark McCulley, "Focus on Swing", Jul. 1998, JavaWorld, 
pp. WS.* 

IBM Technical Disclosure Bulletin, 'Increasing the Usabil- 
ity of Focus-Driven Information Line Text", Jul. 1995, IBM 
Corporation pp. 217-218.* 

* cited by examiner 

Primary Examiner— John Cabeca 

Assistant Examiner— -X. L. Bautista 

(74) Attorney, Agent, or Firm— Rosenthal & Osha L.L.P. 

(57) ABSTRACT 

A method for keyboard navigation in a graphical user 
interface, including defining a key event dispatcher for focus 
ordering of at least one non-focusable component, config- 
ured to recognize a special mode entry character and a 
special mode exit character, upon entry of the special mode 
entry character by a user, entering a special mode wherein 
subsequent key events are manipulated by the key event 
dispatcher to navigate the focus ordering of the at least one 
non-focusable component while a current focus owner is 
maintained, and exiting the special mode upon entry of the 
special mode exit character by the user, wherein the special 
mode is at least one of the group consisting of an input 
method mode, an accessible navigation mode and a window 
navigation mode. 
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KEYBOARD NAVIGATION OF NON- 
FOCUSABLE COMPONENTS 

BACKGROUND OF THE INVENTION 

1 . Technical Field 

The invention relates to windowing toolkits for comput- 
ers. 

2. Background Art 

The basic functionality of a computer is dictated both by 
the hardware of the computer and by the type of operating 
system it uses. Various operating systems exist in the 
marketplace, including Solaris from Sun Microsystems, 
Mac OS from Apple Computer, the "Windows" operating 
systems, e.g., Windows 95/98 and Windows NT, from 
Microsoft, and Linux. A given combination of computer 
hardware, an operating system, and a windowing system 
will be referred to herein as a "platform". Prior to the 
popularity of the Internet, software developers wrote pro- 
grams specifically designed for individual platforms. Thus, 
a program written for one platform could not be run on 
another. However, the advent of the Internet made cross- 
platform compatibility a necessity. 

Prior art FIG. 1 illustrates a conceptional arrangement 
wherein a first computer 3 running the Solaris platform and 
a second computer 5 running the Windows 98 platform are 
connected to a server 9 via the Internet 7. A resource 
provider using the server 9 might be any type of business, 
governmental, or educational institution. The resource pro- 
vider has a need to be able to provide its resources to both 
the user of the Solaris platform and the user of the Windows 
98 platform, but does not have the luxury of being able to 
custom-design its content for the individual platforms. 

Trlg^ga^p^^raminmg language was developed by Sun 
Microsystems to address this problem. The Java™ program- 
ming language was designed to be simple for the program- 
mer to use, yet to be able to run securely over a network and 
work on a wide range of platforms. 

Referring to FIG. 2, in order to create a Java™ 
application, the developer first writes the application in 
human-readable Java™ source code. As used herein, the 
term "application" refers to both true Java™ applications 
and Java™ "applets'* which are essentially small applica- 
tions usually embedded in a web page. In the example 
shown, the application "Program" 11 is created as a human- 
readable text file. The name of this text file is given the 
required character extension "Java". 

A Java™ compiler such as Sun Microsystem's "javac" 13 
is used to compile the source code into a machine -readable 
binary file 15. Hie text file will contain Java™ language 
commands, e.g., "import java.awt.Frame". A discussion of 
the Java™ language itself is beyond the scope of this 
document. However, complete information regarding the 
Java™ program language is available from Sun Microsys- 
tems both in print and via the Internet atjava.sun.com. The 
resulting binary file 15 will automatically receive the same 
file name as the source text file, but will use ".class" as the 
trailing extension. The Java™ runtime environment incor- 
porates a Java™ "virtual machine" (JVM) 16 to convert the 
".class" byte codes into actual machine executions 17. The 
machine executions (like drawing windows, buttons, and 
user prompt fields) will occur in accordance to the applica- 
tion developer's code instructions. Because Sun Microsys- 
tems specifically designed the JVM to run on different 
platforms, a single set of ".class" byte codes will execute on 
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any platform where a JVM has been installed. An Internet 
browser such as Netscape Navigator and Microsoft Explorer 
that incorporates a JVM is called a "Java™ enabled" 
browser. ^ . _ 

5 ^^^^^^offi^m^^cmre-of the Java™ program- 
^in^Janguage.is illustrated in FIG. 3, which shows how the 
Java™ language enables cross-platform applications over 
th£ Internet, In the figure, the computer 3 running the Solaris 
platform and the computer 5 running the Windows 98 

30 platform are each provided with a Java™ virtual machine 
21. The resource provider creates a Java™ application using 
the Java™ software development kit ("SDK") 23 and makes 
the complied Java™ byte codes available on the server 9, 
which in this example is running on a Windows NT plat- 
form. Through standard Internet protocols, both the com- 

15 puter 3 and the computer 5 may obtain a copy of the same 
byte codes and, despite the difference in platforms, execute 
the byte codes through their respective JVM. 

FIG, 4 illustrates an exemplary display on a screen 31 
including top-level windows 33, 34, and 35. Each window 

20 includes a title bar 37 for displaying the title of the window 
and, if applicable, a menu bar 39 containing a number of pull 
down menu buttons defined by the developer. In this 
example, window 34 is the "active" window, as indicated by 
the darkened title bar. Windows 33 and 35 are inactive as 

25 indicated by the grayed out title bar. The window 33 includes 
a number of typical components, including "radio buttons" 
41 which in this case allow the user to select a prefix, a text 
field 43 for entering a name, and an address field 45 for 
entering an address. Component 47 is a "chooser", allowing 

30 the user to choose a state. Components 49 are check boxes 
that allow the user to check one or all of the options that 
apply. Associated with these check boxes are additional 
radio buttons 51 and 53 that allow the user to select a desired 
means of transmission. If the "quote" check box 49 is 
selected and the telephone radio button is selected, the 
window 34 appears allowing the user to enter telephone 

f?, numbers. An additional text area 57 is associated with the 

| "other" check box 49. Finally, "submit" and "reset" buttons 

| 59 are provided to allow the user to either submit the form 

* or reset it. 

40 When developing a graphical user interface (GUI) such as 
the example shown in FIG. 4, one issue for consideration by 
the application developer is the concept of "focus". 
Traditionally, the "focus owner*' is the component that, at a 
given time, receives keyboard input generated by the appli- 

45 cation user. The user, of course, has the ability to transfer 
focus between components. The primary method for chang- 
ing focus is by clicking on a new component using a mouse. 
However, an alternate way of changing focus is by using the 
keyboard. Using the keyboard to change focus is referred to 

50 as "focus traversal". Typically, focus traversal is achieved 
using pre-defined keys on the keyboard (for example, the 
TAB key) or some equivalent device in an accessible envi- 
ronment. For example, referring again to FIG. 4, a cursor 61 
(which would be blinking) is shown in the "home phone" 

55 text field 62, This means component 62 is the focus owner, 
and keyboard input generated by the user would be sent to 
that field. Typically, the user may then move to the next 
component ("cell phone") without using the mouse by 
simply hitting the TAB key, or return to the previous 

60 component ("work number") by hitting SHIFT-TAB. This is 
referred to as forward and backward focus traversal, respec- 
tively. In addition to user-initiated traversal, client code can 
also initiate traversal programmatically. 

65 SUMMARY OF THE INVENTION 

In one aspect, the invention relates to a method for 
keyboard navigation in a graphical user interface, compris- 
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ing: defining a key event dispatcher configured to recognize 
a special mode entry character and a special mode exit 
character; upon entry of the special mode entry character by 
a user, entering a special mode wherein subsequent key 
events are manipulated by the key event dispatcher while a 
current focus owner is maintained; and exiting the special 
mode upon entry of the special mode exit character by the 
user. In some embodiments, the special mode comprises an 
input method mode, and wherein manipulation of subse- 
quent key events comprises diverting key events to an input 
method object. 

In some embodiments, the special mode comprises an 
accessible navigation mode, and wherein manipulation of 
subsequent key events comprises using the key events to 
navigate the graphical user interface in accordance with an 
accessible navigation policy. 

In some embodiments, the special mode comprises a 
window navigation mode, and wherein manipulation of 
subsequent key events comprises using the key events to 
navigate a plurality of windows in accordance with a win- 
dow navigation policy. 

In another aspect, the invention relates to a windowing 
toolkit for development of a graphical user interface, the 
toolkit comprising a plurality of tools having code suitable 
to be executed by a computer, the toolkit comprising: a first 
tool for defining a special mode entry character and a special 
mode exit character; a second tool for defining a special 
mode to be entered upon entry of the special mode entry 
character and to be exited upon entry of the special mode 
exit character, the second tool providing a manipulation 
mechanism by which key events are manipulated while in 
the special mode and while maintaining a current focus 
owner. 

In some embodiments, the special mode defined by the 
second tool comprises an input method mode, and wherein 
the manipulation mechanism diverts key events to an input 
method object. 

In some embodiments, the special mode defined by the 
second tool comprises an accessible navigation mode, and 
wherein the manipulation mechanism uses the key events to 
navigate the graphical user interface in accordance with an 
accessible navigation policy. 

In some embodiments, the special mode defined by the 
second tool comprises a window navigation mode, and 
wherein the manipulation mechanism uses the key events to 
navigate a plurality of windows in accordance with a win- 
dow navigation policy. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a multiple platform environment. 
FIG. 2 illustrates a mechanism for creating Java™ appli- 
cations. 

FIG. 3 illustrates a Java™ application running in a 
multiple platform environment. 

FIG. 4 illustrates a typical graphical user interface (GUI). 

FIG. 5 is a schematic illustration of a typical computer 
system. 

FIG. 6 illustrates an example of a "font chooser" palette. 

FIG. 7 is a flowchart illustrating a process in accordance 
with one embodiment of the invention. 

FIG. 8 illustrates an input method embodiment of the 
invention. 

FIG. 9 is a flowchart illustrating a process in accordance 
with the input method embodiment of FIG. 8. 
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FIG. 10 illustrates a graphical user interface in accordance 
with an embodiment of the invention. 

FIG. 11 is a flowchart illustrating a process in accordance 
with the embodiment of FIG. 10. 

FIG. 12 illustrates a graphical user interface in accordance 
with another embodiment of the invention. 

FIG. 13 is a flowchart illustrating a process in accordance 
with the embodiment of FIG. 12. 

10 DETAILED DESCRIPTION OF THE 

INVENTION 

Various embodiments of the invention will now be 
described with reference to the accompanying figures. Like 
i5 elements in the figures are represented by like numerals for 
consistency. 

The invention described herein may be 'im plem:enfe.d ^on ^ 
^a^fl^ platform 
{jbei'rigiused'.- For example7~as~ shown in FIG. 6, a typical 

1Q computer 71 will have a processor 73, associated memory 
75, and numerous other elements and functionalities typical 
to today's computers (not shown). The computer 71 will 
have associated therewith input means such as a keyboard 
77 and a mouse 79, although in an accessible environment 

25 these input means may take other forms such as a special 
input device designed for a disabled user. The computer 71 
will also be associated with an output device such as a 
display 81, which may also take a different form in an 
accessible environment. Computer 71 is connected via a 

30 connection means 83 to the Internet 7. The computer 71 is 
configured to run a Java™ virtual machine 21, implemented 
either in hardware or in software. 

As explained above, existing windowing toolkits define 
the "focus owner" as the component on the screen that 

35 receives keystrokes input by the user. Although the mouse is 
the primary means of changing focus, the user usually is also 
provided with a way of using the keyboard to change which 
component is the focus owner. This process is referred to as 
"focus traversal". Typically, focus traversal reaches only 

40 those components that expect to receive keystrokes. This is 
because it would be a waste of time to force the user to 
traverse through labels and other fields that do not accept 
keystrokes. Returning to FIG. 4 for example, while a typical 
user would want to be able to traverse, e.g., radio buttons 41 

45 and text field 43, the user would not want to have to traverse 
also through the labels "PREFIX", "MR", "MS", "DR", and 
"NAME". These labels can simply be read on the screen. 
Thus, labels normally cannot be reached using focus tra- 
versal. 

50 Another example is a window such as a font chooser 81 
shown in FIG. 6. No component in this window ever expects 
keystrokes, so typically no component in the window can be 
reached by focus traversal. Although the developer may 
define "keyboard short-cuts" as an alternative way to access 

55 the functionality of such windows, it is desirable to provide 
the developer with a mechanism by which this can be 
achieved using keyboard navigation as well. 
'^yA^sy^m is referred to as "accessible" if it can be used by 
a disabled user. Many levels and types of accessibility exist 

60 given Ihe many types of disab ili ties that must be considered. 
"Taking, for example, a system accessible to blind users, the 
user must be able to navigate every component on a screen 
via the keyboard so that the component's description can be 
read out by a screen reader jlowever, this is at odds with the 

65 definition above that only components desiring keyboard 
input are reachable by keyboard navigation. For example, a 
window acting as a font chooser (regardless of whether part 
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of an application written in Java™, VisualBasic, J++, 
HTML, etc.) does not typically use keyboard input as 
explained above. In other words, such a window will not 
typically need or want focus because a mouse is the common 
method of interacting with such palette windows. Yet, a 
custom application designed for a blind user would need to 
allow for non-mouse input on such a font chooser window. 
Thus, in the area of focus management, the current focus 
model forces the application developer to expend double 
effort on parallel development of standard and specialized 
applications. This font chooser window scenario highlights 
the fact that current GUI software development kits (SDKs) 
do not provide easy and elegant means to create source code 
that supports the traditional focus model as well as special 
models (where non-focusable components need awareness 
of events normally known only by those components with 
focus). 

In accordance with the above, the invention provides a 
mechanism by which keyboard navigation of all windows 
and components in a given application is possible, while at 
the same time retaining the non-focusable properties of the 
normally non-reachable windows and components and with- 
out stealing focus from a currently focused component. 
Thus, an important feature of the invention is the ability to 
deliver key events (i.e., keystrokes) to non-focused compo- 
nents without affecting the current focus status. In one 
embodiment, this may be achieved by registering one or 
more "key event dispatchers*' with a "keyboard focus man- 
ager 1 ' , The keyboard focus manager is responsible for dis- 
patching all user-generated key events and serves as a 
gateway between key input from the user and delivery of the 
key event to the focus owner. The key event dispatcher 
cooperates with the keyboard focus manager in the targeting 
and dispatching of key events. Registered key event dis- 
patchers will receive key events before the events are 
dispatched by the keyboard focus manager to the focus 
owner. Thus, the key event dispatcher is able to retarget the 
event, consume it, dispatch it itself, edit the event, and/or 
deliver it to components other than the current "true" focus 
owner. 

The above process is further explained with reference to 
FIG. 7. In this figure, at SHOO a key input is made by a user. 
The key input is then applied to the keyboard focus manager 
(ST103). The keyboard focus manager then determines if a 
registered key event dispatcher is implicated by the key 
input (SH05). If the response to this inquiry is no, the key 
event is delivered to the current focus owner (ST107). If a 
registered key event dispatcher is implicated, the key event 
is then modified, consumed, and/or re-targeted by the key 
event dispatcher in accordance with its definition (SH09). 
This definition may include, for example, editing the key 
event and returning it to the keyboard focus manager for 
delivery to the current focus owner, delivering the key event 
itself, consuming the key event altogether, or delivering the 
event to a component other than the current focus owner. 
Thus, the application developer will have greatly enhanced 
flexibility to address focus traversal issues, particularly with 
respect to accessibility, without hindering or compromising 
other features of current windowing toolkits. 

One example of an application of the key event dispatcher 
of the invention is "input method" implementation. An input 
method is a way of combining multiple keystrokes to create 
entry characters that are not available on the keyboard. For 
example, input methods are used to allow input in a lan- 
guage written in a character set other than that supported by 
the available keyboard. Input methods are often used, for 
example, to enable entry of Chinese characters or "kanji" by 
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inputting a phonetic representation using Latin characters 
and then selecting from a menu of possible kanji. In a typical 
application, as the user types input to a text field, the user 
will type a predefined character, such as a space, to signal the 

5 start of a keystroke sequence that is to be interpreted as a 
special character. A drop-down box then appears allowing 
the user to select a non-standard character from a list of 
choices. Once a choice is made, the non-standard character 
is placed in the text field, replacing the Latin phonetic 

10 representative. 

In the preceding example, focus must remain in the text 
field even while the user is selecting a choice from the 
drop-down box. This is necessary so that the cursor will 
continue to blink. Another reason for this is that text fields 

15 often employ an input verification mechanism by which it is 
determined whether the entered characters are of the right 
type or in the right format when that field loses focus. If the 
input verification mechanism detects an error, an error 
message typically will be displayed and the user will be 

20 prompted to re-enter the information. Clearly, in the input 
method example, it would be undesirable to have an input 
verification mechanism triggered by a change of focus to the 
drop-down box, because the user would not yet have entered 
the desired information. Thus, this presents a problem for the 

25 typical focus model, where focus would be stolen by the 
drop-down box upon selection by the user. 

A key event dispatcher may be used to implement input 
methods by defining the special characters that signal the 
beginning and end of a keystroke sequence. The key event 

30 dispatcher also remembers the current state so as to deter- 
mine whether keystrokes should be diverted to the input 
method or applied directly to the focus field. When in the 
"input method mode", the key event dispatcher retargets key 
events to the input method until an end of the sequence is 

35 signaled. Using the key event dispatcher to implement input 
methods therefore allows the actual input focus to stay in the 
text field which is receiving input and allows the top-level 
window ancestor of the text field to remain active. 

One possible implementation in accordance with this 

40 embodiment of the invention is illustrated by FIG. 8 in 
combination with the flowchart of FIG. 9. In FIG. 8, window 
33 is again the active window. In this example, the user 
wishes to enter information in the address field 45 using a 
character set other than that provided on the user's keyboard. 

45 Thus, use of an input method is desirable. In order to use an 
input method implemented in accordance with the invention, 
the user first inputs an input method entry character (ST271). 
The key event dispatcher recognizes the input method entry 
character, and enters the input method mode (ST273). The 

50 input method, which may be third party software, then 
creates a drop-down box 40 with a list of choices corre- 
sponding to the entered characters (only one is shown). The 
key event dispatcher diverts further keystrokes to the input 
method, but maintains the current focus owner (ST275). 

55 Thus, using the example of a Japanese language input 
method, the user could enter the word "nihon" (the Japanese 
word for Japan) in Latin characters in field 45. Upon 
completion of entry of this word, the user would choose an 
appropriate entry from the list in drop-down box 40 using a 

60 special key defined by the input method. When character 
delivery is indicated by the input method (ST277), the 
characters corresponding to "nihon" are applied to the 
current focus owner (ST279). Thus, the Japanese kanji for 
the word nihon would replace the Latin characters in address 

65 field 45. When the user is done with the input method, the 
user inputs the input method exit character (ST281), causing 
the key event dispatcher to exit the input method mode 
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(ST283). The input method of FIG. 8 is but one possible 
approach; many types of input methods exist and may be 
implemented in accordance with the invention as explained 
above. 

Exemplary applications of the invention to an accessible s 
environment will now be discussed. As explained 
previously, in order for a system to be accessible to blind 
users, an application must allow keyboard navigation to 
each of its components, including those that normally do not 
accept keyboard input. This is necessary so that, for 10 
example, a screen reader may read the component's descrip- 
tion. However, in the normal scheme of things the screen 
reader will be unable to reach those components because 
they cannot be reached via keyboard focus traversal. 

To overcome this difficulty, a key event dispatcher may be 15 
used to create a navigation mode wherein components such 
as labels that do not ordinarily accept keyboard input can be 
accessed. To do this, the application developer will establish 
a key event dispatcher that defines special characters sig- 
naling the beginning and the end of a special keyboard 20 
navigation mode, which in this example will be called 
"accessible navigation mode." These special characters may 
be any combination of keystrokes, such as CTRL-ALT-TAB 
or the like. The beginning and end special characters may be 
the same or may be different according to the wishes of the 25 
developer. While in the accessible navigation mode, the key 
event dispatcher will recognize specially denned characters 
as "navigation characters" (e.g., arrow keys), and respond to 
them by navigating through all components in a window 
instead of only those that normally accept keyboard input. 30 
The key event dispatcher will then forward other characters 
typed by the user to the currently navigated, rather than the 
currently focused, component. In this way, a user is able to 
navigate from one component to another (e.g., for the 
purpose of reading the descriptions with a screen reader), 35 
regardless of whether the components are focusable and 
without changing the current focus owner. 

Another specially defined navigation character, "set 
focus", allows the user to transfer keyboard focus to the 4Q 
currently navigated component (if it is a focusable 
component) from the currently focused component. In this 
way, a blind user is able to navigate until he or she finds a 
desired component, and then quickly set focus to that field. 
If the set focus character is entered while the currently 45 
navigated component is a non-focusable component, an 
error is indicated, but no focus transfer occurs. 

The manner in which components are traversed in the 
accessible navigation mode is set by an "accessible key- 
board navigation policy." The accessible keyboard naviga- 50 
tion policy may be, for example, a policy whereby compo- 
nents are navigated in the order they appear in the window. 
However, the application developer has the freedom to alter 
the accessible keyboard navigation policy as desired to suit 
the needs of a particular application. 55 

An example of one implementation of this embodiment of 
the invention will now be discussed with reference to FIG. 
10. As can be seen, FIG. 10 bears resemblance to FIG. 4 
except that window 34 has been removed and window 33 is 
now the active window. If, for example, focus is currently in 60 
the field denoted by "MR" in the radio buttons 41 (as shown 
by the dotted circle), in accordance with normal focus 
traversal behavior two strokes of the TAB key would bring 
focus to the radio button "DR", and a third might bring the 
cursor into text field 43. An additional stroke of the TAB key 65 
will move the cursor into text field 45, and so on throughout 
the entire window. Consider then an accessible environment 
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where a blind user employs a screen reader. When the cursor 
skips from the radio buttons 41 to the text field 43 without 
navigating the label "NAME;", the blind user has no idea 
what text is to be entered into text field 43. Thus, in 
accordance with the invention, upon entry into window 33 
the user in an accessible environment would enter the 
accessible navigation mode entry character as indicated in 
the flowchart of FIG. 11 (ST201). Upon entry of this 
character, the key event dispatcher registered with the key- 
board focus manager recognizes the special character and 
enters accessible navigation mode (ST203). The user may 
then input a character (ST204). The key event dispatcher 
then looks to see if a navigation character has been entered 
(ST205). If the answer is yes, the system will navigate to a 
new component according to the accessible keyboard navi- 
gation policy (ST207). As noted previously, the accessible 
keyboard navigation policy may be set in accordance with 
the developer's wishes. However, any window for which a 
policy is not explicitly defined may, for example, inherit its 
policy from an application default. The application default 
may, for example, establish a navigation policy by which 
every component in the window is navigated in the order it 
appears in the window. 

Returning to the flowchart of FIG. 11, the key event 
dispatcher also monitors keystrokes to determine if the set 
focus character has been entered (ST209). If the set focus 
character is entered, the key event dispatcher then deter- 
mines if the currently registered component is focusable 
(ST211). If so, the current focus owner is set to the current 
navigated component (ST213), and accessible navigation 
mode is exited. When in accessible navigation mode, the key 
event dispatcher also monitors keystrokes to determine if the 
accessible navigation exit mode character has been entered 
(ST217). If so, accessible navigation mode is exited 
(ST215). Thus, returning now to FIG. 10, in accessible 
navigation mode the user would be able to access, using the 
keyboard or an equivalent device, not only those compo- 
nents that normally accept keystrokes, but all components in 
the window. Once a component of interest is located, the 
user can easily set focus to that component by entering the 
set focus character. 

Application of the keyboard focus manager and the key 
event dispatcher to navigation of special types of windows 
will now be described. Windowing toolkits define certain 
windows, such as floating palettes, that do not ever want to 
be the active or focused window. Although an application 
may be written to provide a blind user with another means 
of accessing the functionality of these windows using, for 
example, keyboard short-cuts, a more elegant solution is to 
allow keyboard navigation to such windows as well. The key 
event dispatcher can be used to navigate to such windows by 
defining a special character to start a "window navigation 
mode," The actual key or keys making up the special 
character can be defined as the developer desires. While in 
this mode, another special window navigation character 
(which could be the same character used to enter the mode) 
is used to move to the next window in an application context. 
Such navigation does not affect the currently active window 
or the currently focused component. The key event dis- 
patcher also defines another special character to exit window 
navigation mode and return to normal key event processing. 
In this way, keyboard navigation to non-active windows in 
an accessible environment may be achieved without stealing 
focus from the currently focused component in the active 
window and without necessitating a customized program- 
matic solution. 

One implementation in accordance with this embodiment 
of the invention is illustrated by the screen shown in FIG. 12 



05/20/2004, EAST Version: 1.4.1 



US 6,654,038 Bl 

9 10 

in combination with the flowchart of FIG. 13. In the illus- ognize a special mode entry character and a special 

tration of FIG. 12, window 33 is again the active window. mode exit character; 

However, a font chooser 36 is shown that allows the user to upon entry of the special mode entry character by a user, 

select a font while entering a name in, for example, field 43. enlerin a ial mode wherein subsequenl key events 

Normal keyboard navigation would never reach the font s are manipulated by the key event dispatcher to navigate 

chooser because it can never be an active window and does ^ focus ^ Qf ^ a ^ Qne non . focusable 

not want to accept keystrokes. Moreover, focus must remaiD , , . t ° 4 £ . . . . , 

a \a a*l a * • <. *• i • a component while a current focus owner is maintained; 

with field 43 due to input verification concerns as explained , v 

previously, among others. Nonetheless, it is desirable to 

provide a mechanism by which the user in an accessible exiting the special mode upon entry of the special mode 

environment can reach this window by focus traversal. In ex ^ character by the user, 

order to reach the font chooser, the user first inputs a window wherein the special mode is at least one of the group 

navigation mode entry character (ST251). The key event consisting of an input method mode, an accessible 

dispatcher recognizes the window navigation mode entry navigation mode and a window navigation mode, 

character, and enters the window navigation mode (ST253). 15 2. The method of claim 1 wherein the input method mode 

The key event dispatcher then diverts further keystrokes comprises manipulation of subsequent key events by divert- 

based on the window keyboard navigation policy, but main- ing key events to an input method object, 

tains the current focus owner (ST255). In the case shown in 3. The method of claim 2, further comprising delivering 

FIG. 12, after entering the window navigation mode, the characters to the current focus owner in response to a 

user might employ the window navigation character to move 2Q delivery indication from the input method object, 

between windows. Once in the correct window, the user 4. The method of claim 1, wherein the accessible navi- 

typically will then want to enter accessible navigation mode gation mode comprises manipulation of subsequent key 

to navigate the components of the new window. In this way, events by using the key events to navigate the graphical user 

the user can employ window navigation made to reach the interface in accordance with an accessible navigation policy, 

desired window, and then employ accessible navigation 25 5. The method of claim 4, wherein the key event dis- 

mode to reach the desired component within that window. patcher is further configured to recognize a set focus 

Returning to FIG. 12, for example, consider a case where the character, and further comprising changing focus from the 

user wants to enter bold text in field 43, The user would first current focus owner to a currently navigated component 

reach font chooser 36 using window navigation mode, and upon entry of the set focus character by the user, 

then use accessible navigation mode to reach the "Bold" 3Q 6. The method of claim 4, further comprising reading a 

component. The user would next enter a pre-defined key currently navigated component using a screen reader, 

such as the space bar, which would make the entered text 7. The method of claim 1, wherein the window navigation 

bold. mode comprises manipulation of subsequent key events by 

While in window navigation mode, the key event dis- using the key events to navigate a plurality of windows in 

patcher monitors the keystrokes entered by the user to 35 accordance with a window navigation policy, 

determine if the window navigation exit character is entered 8. The method of claim 7, further comprising reading a 

(ST257). If it is, the window navigation mode is exited currently navigated component using a screen reader. 

(ST258). 9. The method of claim 7, wherein the accessible navi- 

As a result of the invention, the developer is provided g ation mode comprising manipulation of subsequent key 

with a mechanism by which access to non-focusable com- 40 events and further comprises using the key events to navi- 

ponents can be more easily established. The developer is g ate a currently navigated window in accordance with an 

provided with a toolkit containing a collection of tools accessible navigation policy. 

implemented, for example, in the Java™ programming 10 - A windowing toolkit for development of a graphical 

language as shown in FIG. 2 and suitable for execution by user interface, the toolkit comprising a plurality of tools 

a computer such as that shown in FIG. 5. The tools allow the 45 havin g code suitable to be executed by a computer, the 

developer to define, for example, key dispatchers for input toolkit comprising: 

method objects, accessible navigation modes, and window a first tool for defining a special mode entry character and 

navigation modes, without necessitating custom program- a special mode exit character; and 

matic solutions. a second tool for defining a special mode for focus 

Although the invention has been described above in 50 ordering of at least one non-focusable component, to be 

connection with the Java™ programming language, the entered upon entry of the special mode entry character 

invention may be implemented in any language in a cross- and to be exited upon entry of the special mode exit 

platform context or on a particular platform. Although the character, the second tool providing a manipulation 

invention has been described above with respect to particu- mechanism by which key events are manipulated to 

lar examples, the applicability of the invention is not limited 55 navigate the focus ordering of the at least one non- 

to these specific instances. An application developer will focusable component while in the special mode and 

find multiple avenues of applicability for the invention that while maintaining a current focus owner, 

both enhance functionality and accessibility for the end user wherein the special mode is at least one of the group 

and simplify the development process. Accordingly, the consisting of an input method mode, an accessible 

invention is not limited to the embodiments described or the eo navigation mode and a window navigation mode, 

examples discussed, but rather is limited only by the scope 11. The windowing toolkit of claim 10, wherein the 

of the appending claims. manipulation mechanism diverts key events to an input 

What is claimed is: method object while in the input method mode. 

1. A method for keyboard navigation in a graphical user 12. The method of claim 11, wherein the manipulation 

interface, comprising: 65 mechanism delivers characters to the current focus owner in 

defining a key event dispatcher for focus ordering of at response to a delivery indication from the input method 

least one non-focusable component, configured to rec- object. 
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13. The windowing toolkit of claim 10, wherein the 
manipulation mechanism uses the key events to navigate the 
graphical user interface in accordance with an accessible 
navigation policy while in the accessible navigation mode. 

14. The windowing toolkit of claim 13, wherein the first 5 
tool further defines a set focus character, and wherein the 
second tool provides for transfer of focus from the current 
focus owner to a currently navigated component upon entry 
of the set focus character. 

15. The windowing toolkit of claim 13, wherein the 10 
accessible navigation policy provides for navigation to non- 
focusable components of the graphical user interface. 

16. The windowing toolkit of claim 10, wherein the 
manipulation mechanism uses the key events to navigate a 
plurality of windows in accordance with a window naviga- 15 
tion policy while in the window navigation mode. 
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17. The windowing toolkit of claim 16, wherein the first 
tool further defines a set focus character, and wherein the 
second tool provides for transfer of focus from the current 
focus owner to a currently navigated component upon entry 
of the set focus character. 

18. The windowing toolkit of claim 16, wherein the 
window navigation policy provides for navigation to a 
window that cannot be an active window. 

19. The windowing toolkit of claim 16, wherein the 
special mode defined by the second tool further comprises 
the accessible navigation mode, and wherein the manipula- 
tion mechanism uses the key events to navigate a currently 
navigated window in accordance with an accessible navi- 
gation policy. 

* * * * * 
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